1. Technical Field of the Invention
The present invention relates to systems for, and methods of, exchanging information between software modules. More particularly, the present invention relates to systems for, and methods, of exchanging information between software modules, wherein a brokering service is provided to manage callback interfaces between notifiers and observers.
2. Description of the Related Art
Object-oriented computer programming (xe2x80x9cOOPxe2x80x9d) deconstructs a high-level operation performed by a computer application into discrete modules known in the art as xe2x80x9cobjectsxe2x80x9d or xe2x80x9ccomponents.xe2x80x9d Prior to OOP, computer applications typically contained program code for each task which may be executed during the application""s high-level operation. However, OOP allows a computer application to contain only the program code which is minimally necessary for the operative structure or framework of the application""s high-level operation. Each specific task to be performed during the computer application""s high-level operation, then, is provided as a component which is itself xe2x80x9ccalledxe2x80x9d into the framework of the computer application on an as-needed basis. Component-based programming platforms known to those of ordinary skill in the art, such as Component Object Model (xe2x80x9cCOMxe2x80x9d), distributed by Microsoft Corporation of Seattle, Wash., or Common Object Request Broker Architecture (xe2x80x9cCORBAxe2x80x9d), promulgated by Object Management Group of Framingham, Mass., were developed for the purpose of designing modular computer applications.
Generally, objects may be considered to be either xe2x80x9cobserversxe2x80x9d or xe2x80x9cnotifiersxe2x80x9d or both which commonly reside within discrete addressable locations of a computer""s memory. An observer is responsible for performing some predefined operation in response to detection by a notifier of a predetermined triggering event. For example, in a telecommunications network, the observer may be an automated voicemail application which is responsible for playing a prerecorded message and recording an incoming message when an incoming telephone call is routed to voicemail. The notifier may be connected to a telephone line to detect an incoming call which is reported to the observer thus triggering the voicemail application. It is therefore desirable to provide a system for, and method of, transmitting a message from a notifier component to an observer component upon the happening of a predetermined triggering event.
One known method for an observer to be advised of the happening of a triggering event involves having the observer periodically poll the notifier to determine the status of the notifier. For example, the notifier may contain a memory flag which is in a logical xe2x80x9cupxe2x80x9d position when it detects an incoming call on the line and which is in a logical xe2x80x9cdownxe2x80x9d position at all other times. Upon polling the notifier, if the observer detects that the flag is in the xe2x80x9cupxe2x80x9d position, it thereby detects the happening of the triggering event and initiates the automated voicemail application. According to this method, however, the observer must poll the notifier at frequent, predetermined intervals to determine the position of the flag. Such repeated polling consumes substantial operating time and can create operating problems, for example, when the notifier is removed from the system. Moreover, polling the notifier is a totally useless operation most of the time since the status of the flag does not change frequently. Thus, polling reduces overall system performance and efficiency. Accordingly, it is desirable to provide a system for, and method of, exchanging information between software modules, wherein unnecessary polling or querying of a notifier by an observer is minimized or altogether eliminated.
Another known method of notifying an observer of the happening of a triggering event is for the notifier to spontaneously transmit a message to the observer when a triggering event occurs. For example, an object-based platform, such as COM, can establish a xe2x80x9ccallback interfacexe2x80x9d between the observer and the notifier, whereby the observer has beforehand registered with the notifier the observer""s interest in being notified upon the happening of a triggering event. Typically, the observer initiates the procedure of establishing the callback interface by locating the notifier, querying the notifier to determine whether the notifier is adapted to detect the happening of the triggering event which is of interest to the observer, and if so, determining if the notifier is adapted to advise the observer of the happening of the triggering event. If so, the observer registers with the notifier the observer""s interest in being notified when the triggering event occurs.
Unfortunately, the process by which the callback interface is established according to known methods requires several queries and messages to be exchanged between the observer and the notifier. Moreover, an observer may not know whether, or where, a notifier resides on the server which may detect triggering events of interest to the observer. As such, an observer may operate completely ignorant of the fact that it could take advantage of the notification services of a notifier existing in the system, but fails to do so only because it is unaware of the notifier""s existence. To find notifiers offering notification services of interest to the observer with which the observer desires to establish a callback interface, then, requires the observer to search the entire system looking for notifiers which monitor events of interest to the observer and to contact all notifiers in the process, many of which may not monitor events of interest to the observer. It is obvious that the search for and querying of each notifier found on the system significantly reduces overall system performance and efficiency. It is therefore desirable to provide a system for, and method of, establishing a callback interface between an observer and a notifier, wherein minimal searching and querying is required for observers to establish callback interfaces with notifiers.
To this end, a directory service is sometimes provided on a system with a look-up table containing the locations of any notifiers on the system and the class of events the notifiers respectively monitor. For example, as each notifier is created, an entry is created in the directory service look-up table for that notifier having the location of the notifier and the class of events it monitors. Rather than searching the system at large for a notifier which monitors a particular class of events, an observer, when it becomes interested in receiving notification from a notifier, consults the directory service look-up table to find those notifiers registered therein which monitor a class of events of interest to the observer. For example, upon its creation the line-monitoring notifier of the above example would register its location alongside a reference to its monitoring the unanswered status of a telephone line. The voicemail observer, then, upon consulting the directory service, would determine that the line-monitoring notifier monitors an event class of interest to it and would directly initiate a callback relationship with the line-monitoring notifier. Because the directory service points the observer directly to the notifier, the observer is not required to search the system for it, thereby improving overall system performance and efficiency. However, it is not always desirable for an observer to be pointed directly to a notifier. For example, disclosing the location of the notifier to other objects, such as the observer, may present security issues. Moreover, while a directory service reduces the searching and querying required for observers to establish callback interfaces with notifiers, observers need to poll the service to determine whether new notifiers have been created.
An event service is sometimes provided as an alternative to a directory service, whereby messaging is routed through the event service such that, as notifiers and observers are created in and removed from the system, notifiers do not transmit messages to observers which have been removed, but have failed to instruct their notifiers accordingly. Moreover, using an event service, observers need not poll the system to find desirable notifiers. Rather, an event service receives all notification messages from all notifiers in the system and forwards the messages to observers which have registered an interest in receiving messages having a preselected event class. Unfortunately, event services oftentimes create a bottleneck in the system, thereby decreasing overall system performance and efficiency. System performance is particularly reduced by using an event service where the data passing through the event service is especially dense, such as, for example, streaming audio or video. Further, all of the existing arrangements lack a viable interface recovery procedure when components are removed from service and restored.
Accordingly, there is a need in the art for a system and method for exchanging information between software modules wherein the messages are passed directly between the modules without the heretofore actions required on the part of the components and the potentially restrictive form of directory services or event services.
This need is met by the invention of the present application wherein a system includes a brokering arrangement for exchanging information between software modules including notifiers adapted to detect the happening of predetermined triggering events having corresponding event classes and observers interested in receiving notification of the happenings of the triggering events. The system includes a broker, observers, and notifiers. In the illustrated embodiment, a creator creates the broker, the observers and the notifiers with the creator creating the software modules in discrete addressable locations of its computer""s memory or the memories of multiple computers interconnected through a network. The broker maintains one or more look-up tables having the identities and locations of all notifier and observer modules existing in the system, as well as the classes of events with which the modules are concerned.
Upon creation of a new notifier or observer module, the creator informs the broker that a newly-created module has been created in the system, and points the broker to the new module""s location. Once connected to the new module, the broker queries the module to determine if it offers notification services, i.e., if it is a notifier. If not, the broker takes no further action with respect to the newly-created module. If the broker determines that the newly-created module offers notification services, the broker adds the notifier to a first or notifiers look-up table, along with the notifier""s event class.
An observer existing in the system, whether or not the observer was created by the creator, finds the broker for the purpose of subscribing to a notification service which is offered by one or more notifiers in the system to advise of an event class or classes of interest to the observer. Once the observer subscribes to any such notification service via the broker, the broker adds the observer to a second or observers look-up table, along with the observer""s event class.
Whenever a notifier or observer has been added to the broker""s look-up tables, the broker compares the notifiers look-up table with the observers look-up table to determine if any notifiers and observers share an event class. In the event the broker determines that a notifier and observer share an event class, the broker sends a message to the notifier, instructing the notifier to send notification of the occurrence of the triggering event directly to the observer. The broker thereby assists in establishing a callback interfaces between notifiers and observers, but is not involved in later communications between the notifiers and observers after the callback interfaces have been established. As new modules are created, and as old modules are removed and/or re-created, the look-up tables are updated so that connection interfaces are created and/or recreated without any action on the part of the observers and notifiers, thereby permitting so-called xe2x80x9chot swappingxe2x80x9d of software modules and automatic recovery of callback interfaces.
In accordance with one aspect of the present invention, a system for exchanging information between software modules comprises a broker which includes a first look-up table for registering modules, notifiers, which notify other modules of the occurrence of one or more triggering events having corresponding event classes and a second look-up table for registering modules, observers, which are to receive notification of one or more triggering events having corresponding event classes. A first notifier is adapted to detect the occurrence of a first predetermined triggering event having a first event class and a first observer is interested in receiving notification of the occurrence of predetermined triggering events having a second event class. The broker adds the first notifier to the first look-up table when the first notifier is created and the broker adds the first observer to the second look-up table when the first observer notifies the broker that it is interested in receiving notification of the predetermined triggering event, i.e., subscribes to the broker""s services. The broker is adapted to compare the first look-up table with the second look-up table such that, upon the broker""s detecting that the first event class and the second event class are the same, the broker instructs the first notifier to notify the first observer directly of the occurrence of the first predetermined triggering event.
In accordance with another aspect of the present invention, a method for exchanging information between software modules comprises the steps of: creating a broker including a first look-up table and a second look-up table; creating a first notifier adapted to detect the occurrence of a first predetermined triggering event having a first event class; the broker listing the first notifier with the first event class in the first look-up table; creating a first observer interested in receiving notification of the occurrence of predetermined triggering events having a second event class; the broker listing the first observer with the second event class in the second look-up table when the first observer notifies the broker that it is interested in being notified of the occurrence of the predetermined triggering event; the broker comparing the first look-up table with the second look-up table; and, the broker instructing the first notifier to notify the first observer directly of the occurrence of the first predetermined triggering event if the first event class and second event class are the same.
It is a feature of the present invention to provide a system and method for exchanging information between software modules. More particularly, it is a feature of the present invention to provide a system and method for brokering communications between notifier modules and observer modules.
It is another feature of the present invention to provide a system and method for exchanging information between software modules wherein unnecessary polling or querying of a notifier by an observer is eliminated.
It is yet another feature of the present invention to provide a system and method for establishing callback interfaces between observer modules and notifier modules wherein searching on the part of observers is not required for observers to establish callback interfaces with notifiers.
It is still another feature of the present invention to provide a system and method for exchanging information between software modules wherein messages are passed directly between the modules.
It is still yet another feature of the present invention to provide a system and method of exchanging information between software modules which is robust and eases the implementation of callback interfaces between notifiers and observers.
It is an additional feature of the present invention to provide a system and method of exchanging information between software modules wherein the recoverability of connections between notifiers and observers is robust in that when new notifier modules are created or when existing modules are removed from service and recreated, the callback interfaces are automatically created, recreated or recovered by the broker.
These and other features and advantages of the present invention will become apparent to those skilled in the art from the description which follows, and may be realized by means of the instrumentalities and combinations particularly pointed out in the claims appended hereto.